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AMENDMENT OF THE SPECIFICATION 

Applicant respectfully requests that the following paragraphs replace corresponding 
paragraphs of the specification. The revisions correct typographical errors and do not add new 
matter: 

[0021] Client-side embodiments may receive the WOL packet at, for instance, a network 

interface card. (NIC), recognize that the WOL packet includes an OSPID that describes the 
bootable image to boot, and implement an alternative boot sequence to boot from that bootable 
image. Some embodiments will delete the OSPED after the first boot to avoid, mistakenly, 
reusing the OSPID to select the bootable image in a subsequent boot. Further embodiments 
include a setting to prevent the OSPID from being deleted, making the bootable image a 
permanent selection. 

[0022] Turning now to the drawings, FIG 1 depicts one embodiment of a data processing 

system 101 for remotely selecting a bootable image via a wake-on-LAN (WOL) packet for a 
WOL capable computer. System 101 includes a server computer system 102 ("server") coupled 
to one or more remote client computer systems 104 ("clients"). The clients may be equipped with 
Wake-on-LAN ("WOL") capability, which provides them with the ability to be "Woken up" 
while in a low-power state and returned to a full power state, and to boot a bootable image 
identified by a operating system partition identification (OSPID) when a WOL-equipped 
network interface card (NIC) receives the appropriate WOL command with the OSPID. WOL is 
also sometimes known as remote wake-up or Magic Pack e t MAGIC PACKET™ technology. In 
system 101, the server 102 and client 104 may be located at the same location, such as in the 
same building or computer lab, or could be geographically separated. While the term "remote" 
is used with reference to the distance between the server 102 and client 104, the term is used in 
the sense of indicating separation of some sort, rather than in the sense of indicating a large 
physical distance between the systems. In fact, the server 102 and client 104 may be physically 
adjacent in some network arrangements. 
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[0038] When the communication subsystem 94 is in WOL mode (e.g., when the client 

104 is asleep), communication subsystem 94 scans all incoming frames addressed to client 104 
for a specific data sequence which indicates that the frame is a WOL or magic packet MAGIC 
PACKET™ frame. WOL packets and frames are described in more detail in relation to FIGS 5 A 
and 5B. If the communication subsystem 94 scans a frame and does not find the appropriate 
WOL sequence, it discards the frame and takes no further action. If it detects the WOL 
sequence, however, it then alerts the power management circuitry 66 to wake up or power on the 
system. 

[0046] As another example, a data packet like data packet 504 having an OSPED is 

depicted in FIG 5B. In FIG 5B, data packet 504 comprises a magic pack e t MAGIC PACKET™ 
frame 514, command extensions 516, and an OSPID packet 518. Magic packet MAGIC 
PACKET™ 514 comprises the source address (server 102 MAC address), destination address 
(e.g., a client 104 MAC address or a multi-cast address for a broadcast magic packet MAGIC 
PACKET™) , and a synchronization stream. The synchronization stream is typically six (6) 
bytes of FFh and is used to help client 104, particularly communication subsystem 94, recognize 
a frame as a magic packet MAGIC PACKET™ frame 5 14. A delineator such as six bytes of FFh 
is easy for hardware to detect and identifies the information as a magic pack e t MAGIC 
PACKET™ 514. hi the embodiment depicted in FIG 5B, the content of magic pack e t MAGIC 
PACKET™ 514 is a six bytes of "FF" followed by 16 copies of MAC addresses (with, for 
example, 8 copies of server MAC address and 8 copies of client MAC address) with no breaks or 
interruptions. In one alternative embodiment, there are 12 copies of MAC addresses, where 6 
copies are client MAC addresses and 6 copies are server MAC addresses. The MAC addresses 
may be located anywhere within the data packet 504 but are preferably preceded by a 
synchronization stream. Client 104 will, in one embodiment, confirm that the magic packet 
MAGIC PACKET™ 104 contains the proper (and proper number of) synchronization stream, 
server MAC address, and client MAC address before initiating the power on process. 

[0047] In an alternative embodiment, a broadcast magic packet MAGIC PACKET™ 5 1 4 

may be used. In this embodiment, the mngic packet MAGIC PACKET™ 514 may be received 
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by all clients 104 on the network and the destination MAC address is listed as, for example, all 
ones (l's). This will indicate to client 104 that the magic pack e t MAGIC PACKET™ 514 is 
intended for it, even though the client MAC address is not included. In another embodiment, a 
multicast broadcast to a specified group of clients 104 may be utilized. 

[0050] When client 104 receives a network packet 500, it is received by physical layer 

and placed on the Mil bus. When network packet 500 comprises a Magic pack e t MAGIC 
PACKET™ 514 (as shown in FIG 6), the MAC detects that it includes Magic pack e t MAGIC 
PACKET™ 514, ignores any command extensions 516, and determines the presence of OSPID 
packet 518. When OSPID packet is present, the OSPID packet is stored in non-volatile memory 
accessible to POST. POST may then instruct the boot manager, or boot loader, to load the boot 
image indicated by OSPID packet 518. 



